home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000123_connolly@pixel.convex.com _Wed Jun 10 01:11:39 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA15414; Wed, 10 Jun 92 01:11:39 MET DST
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA25378; Wed, 10 Jun 92 01:11:32 +0200
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA29288; Tue, 9 Jun 92 18:10:43 -0500
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA20418; Tue, 9 Jun 92 18:10:31 -0500
  10. Message-Id: <9206092310.AA20418@pixel.convex.com>
  11. To: mitra@pandora.sf.ca.us ()
  12. Cc: emv@msen.com, wais-talk@quake.think.com, www-talk@nxoc01.cern.ch,
  13.         gopher-news@boombox.micro.umn.edu
  14. Subject: Re: WAIS APIs 
  15. In-Reply-To: Your message of "Tue, 09 Jun 92 10:08:51 PDT."
  16.              <9206091008.aa08978@pandora.sf.ca.us> 
  17. Date: Tue, 09 Jun 92 18:10:29 CDT
  18. From: Dan Connolly <connolly@pixel.convex.com>
  19.  
  20.  
  21. There are several issues that WAIS and MIME both face. For some
  22. issues, the systems have different requirements, so different
  23. solutions make sense. But for the issue of typing document
  24. content, I feel stronly that WAIS should adopt MIME semantics.
  25.  
  26. WAIS defines a :type field in the :document structure. Right
  27. now, it's a string with loosely defined semantics. It's a
  28. simple matter to obsolete the :type field with a :content-type
  29. field with MIME semantics as follows:
  30.  
  31.     obsolete    MIME compliant
  32.     :type "TEXT"    :content-type "text"
  33.     :type "GIF"    :content-type "image/gif"
  34.     :type "TIFF"    :content-type "image/x-tiff"
  35.     :type "PS"    :content-type "application/postscript"
  36.     :type "WSRC"    :content-type "application/x-wais-source"
  37.     :type "MIME"    :content-type "message"
  38.  
  39. I believe data served up by existing WAIS servers fits the MIME
  40. content typing system as is. A WAIS client already implements the
  41. semantics of the text, image, audio, video, and application types:
  42. Either you present it, hand it off to something that can,
  43. or punt to a file.
  44.  
  45. There are other semantics defined by MIME that would be nice
  46. in WAIS clients. But these require that you handle pretty much
  47. the whole MIME syntax. It's not clear that WAIS should adopt
  48. the MIME solutions in these cases.
  49.  
  50. [I would like to see the world-wide web adopt MIME solutions
  51. for these issues, though.]
  52.  
  53. In <9206081956.AA03908@cmns.think.com.Think.COM>, Mr. Spero suggests
  54. that WAIS might be expanded to offer data in a number of types. The MIME
  55. solution to this problem is the "multipart/alternative" body type.
  56.  
  57. Someone else suggested that the WAIS server might return only
  58. a pointer to the data, and the client could retrieve the actual
  59. content. MIME defines a "message/external-body" type for this.
  60.  
  61. And I suggested that the server might return a complex document
  62. with text, graphics, and pointers to other data. (World Wide
  63. Web servers return text with pointers, and they're trying to
  64. deal with graphics). I suggested a new "multipart/hypertext"
  65. type to handle this.
  66.  
  67. Resolving these issues is going to take a lot more thought.
  68. Let's keep interoperability in mind while we do it.
  69.  
  70. Dan